docs: stop presenting Threadripper 68+68=137 W as a correct RAPL sum - #1
Draft
Dmao233 wants to merge 9 commits into
Draft
docs: stop presenting Threadripper 68+68=137 W as a correct RAPL sum#1Dmao233 wants to merge 9 commits into
Dmao233 wants to merge 9 commits into
Conversation
rapl.md showed two Threadripper dies both reporting 68 W and CodeCarbon totaling 137 W with no warning. Those package-*-die-* domains can mirror one socket-wide counter (mlco2#1274); readers were being taught that 137 W is the right RAPL reading. Annotate the example as the known double-count, and qualify the AMD bullets that told readers to sum every package-X-die-Y domain. Refs mlco2#1392 Co-authored-by: CenFangyu <Dmao233@users.noreply.github.com>
The Windows EMI backend (mlco2#1263) and the Linux RAPL backend (mlco2#1276) both need to detect channels that mirror the same hardware energy counter. Move the tolerance constant and the matching/detection helpers from windows_emi.py to rapl.py, next to RAPLFile, so both backends share one definition instead of duplicating the 1e-6 magic number. No behavior change. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
start() used to permanently remove suspected mirrored counters from self._rapl_files based on a single instantaneous comparison. A file dropped by mistake (two independent packages coincidentally holding the same counter value) was gone for the life of the tracker, and each new start() of a task re-ran the destructive detection on whatever was left. Flag suspected mirrors in a candidate map instead, exactly like the EMI backend does: the files stay monitored, candidates are only left out of the reported details, and every start() re-evaluates the detection from the full set of files. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…ropping Port the second stage of the EMI mirrored-channel detection (mlco2#1263) that the Linux side was missing: a counter flagged at start() is only dropped for good once it has also accumulated the very same energy as its reference over a measurement interval. A candidate whose delta diverges is a real meter and is restored into the measurement; a candidate that has not accumulated anything stays pending until an interval is conclusive. This prevents a genuine second package from being silently discarded for the life of the run because it coincidentally held the same counter value at start. Unlike EMI, which snapshots a device's channels atomically, the powercap sysfs files are read one after the other, so two views of the same counter differ by the energy accrued between the reads. A relative tolerance alone misses true mirrors when the counters are small (right after a wrap-around, which happens every few minutes on packages with a small max_energy_range_uj). Matching therefore also allows an absolute 1 J difference, both when flagging candidates and when comparing deltas; a wrongly flagged independent package is restored by the confirmation stage. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…unters-1274 fix: deduplicate mirrored Linux RAPL counters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
docs/explanation/rapl.mdshowed the Threadripper 1950X teaserpackage-0-die-0: 68 W | package-0-die-1: 68 W | CodeCarbon: 137 Wwith no note that those two dies can report the same socket-wide RAPL counter. That line was easy to read as confirmed-correct behaviour. It is the double-count discussed in mlco2#1274 / mlco2#1276 / mlco2#1379: one meter read twice, so the CPU RAPL value is ~68 W, not 137 W.
This PR only annotates the docs. It does not implement Linux RAPL deduplication (that remains mlco2#1276).
Changes in
docs/explanation/rapl.md:package-X-die-Ydomain.package-0(kernel-dependent).Related Issue
Fixes mlco2#1392
Related: mlco2#1274, mlco2#1276, mlco2#1379
Motivation and Context
Readers were being taught that summing two identical 68 W die readings is the right RAPL result. Whatever lands in mlco2#1276, that example should not stay unannotated.
How Has This Been Tested?
docs/explanation/rapl.mdagainst Linux RAPL over-counts CPU power on multi-die CPUs (port the Windows EMI fix) mlco2/codecarbon#1274 / Linux RAPL may double-count CPU power on multi-die AMD, while Windows EMI explicitly guards against it mlco2/codecarbon#1379 so the note matches the mirrored-counter explanation, not hierarchical psys/package overlap.!!! warningis already used in this docs set.uv run --only-group doc task docs— "No issues found", link check passed. The rendered RAPL page includes theWRONG: 68 W + 68 W = 137 Wannotation and the "Mirrored per-die RAPL counters" admonition.Screenshots (if appropriate):
Not applicable (docs-only).
Types of changes
AI Usage Disclosure
Checklist:
This branch lives on the fork. To open the intended PR against upstream: